$ Header:$
Copyright (c) 1991, 1992, 1993, 1994 by Sam Leffler.
All rights reserved.
This file is provided for unrestricted use provided that this
legend is included on all tape media and as a part of the
software program in whole or part. Users may copy, modify or
distribute this file at will.
This directory contains a program for converting TIFF fax files
to a highly encoded PostScript for printing. In point of fact,
the program can actually handle bilevel TIFF images compressed
with the CCITT Group 3 or Group 4 algorithms. The resultant
PostScript is usually much more efficient to print than the
straightforward "raster dump" generated by tiff2ps.
Consult the manual page for details.
Sam
March 16, 1995
Bret Whissel
Florida State University
Department of Meteorology
bret@ray.met.fsu.edu
This modified version of fax2ps replaces the previous encoding
scheme with font-based encoding, rather than a line-drawing
encoding. Since font characters can be cached by the PostScript
machinery once generated, pixels are rendered much faster than
line-drawn scan conversion.
Only the output encoding section has changed. The TIFF file
reader and fax decoding sections remain intact. There may be
many stray variables and structures hanging around which I
have not removed.
CAVEAT:
I have only tested the output of this program on the two printers
to which I have access: a NEC LC-890, and an Apple LaserWriter
16/600 PS. Ghostscript also had no difficulty rendering the
output. The program itself has compiled on sun4 and sun4c archi-
tectures running gcc version 2.6.3 and gnumake, but again, these
are the only machines to which I have easy access.
I also have not tested this program on the gamut of Fax documents.
I am not able to generate a 2-D encoded or Group4 fax document,
so I don't know how the program will respond. Provided that the
FaxXXDecode() functions produce a real bitstring scanline in all
these cases, I think it will work.
My code may be messy. I'm sure there are more elegant ways to
code the same logic.
METHOD:
A PostScript Type 3 font is created with the following characteristics:
10 Black characters of widths 512, 256, 128, 64, 32, 16, 8, 4, 2, 1
10 White characters of widths 512, 256, 128, 64, 32, 16, 8, 4, 2, 1
64 mixed characters of width 6
-each character looks like it's binary-coded bitvalue, i.e.,
character /0 is blank, character /1 has the rightmost pixel
turned on, ..., character /63 has all 6 pixels turned on.
The scanline bitstring is converted back into a sequence of runlength
values. The first value is assumed to be a run of white, the 2nd, a
run of black, etc. If a runlength (either black or white), is greater
than 6 pixels long, then the variable width black or white characters
are produced until the runlength is reduced to 6 pixels or less.
Short runlengths of black and white are combined, and then a 6-pixel
character is generated.
Since each of the characters may be cached by the PostScript machinery,
the rendering time is greatly reduced.
The black and white variable width characters with width 4, 2, and 1
are not currently used. There is nothing magic about the powers of
two widths: it was merely a functionally complete selection.
The selection of 6-pixel characters was not arbitrary. In generating
a PostScript string for use with the `show' operator, only 92 (maybe
93) font positions can be represented by a single character. A few
require the escape character, and the rest need to be represented
by a 4-character octal code. I did not want to be in the position
of coding 1 pixel with a 4-character sequence.
EMPIRICAL STUFF:
I started out using only the variable-width black and white
characters, but since a different character was needed for every
change of color, and many of the sequences in a complex fax document
involved short runs (1 to 4 pixels of black or white), compression
was enhanced by the mixed-character coding.
No real gain in time or space was eliminated by representing the
initial run of white by a `moveto' rather than printing the whitespace
characters directly, at least with the documents I tested.
Using the original moveto/lineto method, a single page test document
sent at the "FINE" resolution took just over 10 minutes to render on
our aging NEC LC-890 printer. Using the method described here, the
page was completed in under 2 minutes on the same printer, and the
output file was reduced in size from 214.6K to 171.5K.
Bret Whissel
Source
Documentation
Reference
OR, ...